Skip to content

Conversation

embediver
Copy link
Contributor

Add a method to fragment vectored payloads directly.

This eliminates the need to copy vectored payloads to a buffer that can hold the largest possible payload and instead copies the data directly to the packet buffer while fragmenting.

Signed-off-by: Marvin Gudel <marvin.gudel@9elements.com>
Signed-off-by: Marvin Gudel <marvin.gudel@9elements.com>
Copy link
Member

@mkj mkj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, it was on the todo list, good to avoid that buffer. fragment() can be replaced with a call to fragment_vectored() too.

let remaining_payload_len = total_payload_len - self.payload_used;
let l = remaining_payload_len.min(rest.len());
let (d, rest) = rest.split_at_mut(l);
crate::util::copy_vectored(payload, self.payload_used, d);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be a lot of conversion back and forth between total length/offset and slice indices/offsets.

It might simplify the code to remove total_payload_len and payload_used, and instead store current input slice index and offset in Fragmenter? get_sub_slice() wouldn't be needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was thinking something similar while implementing, but just continued bending the existing code until it worked to get a poc.

A "VectorReader" that holds the state and has all of the clean methods like read(), is_at_end(), ... could be nice.
I'll try to come up with something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worked out as I intended.
I'm happy how the Fragmenter looks now.
Maybe there are some nits how to make the reader implementation a bit cleaner, but finding the best way is hard with all the available stuff to access slices.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that looks good.

Signed-off-by: Marvin Gudel <marvin.gudel@9elements.com>
Signed-off-by: Marvin Gudel <marvin.gudel@9elements.com>
@embediver
Copy link
Contributor Author

Noticed, that my code was missing the check for eom to return success in that case.

All the tests seem to just check with is_done() instead of waiting for fragment() to return SendOutput::Complete.
Adding test coverage as a metric to CI and creating a tracking issue for improvements might be a reasonable thing to do.

Signed-off-by: Marvin Gudel <marvin.gudel@9elements.com>
@embediver embediver force-pushed the mgudel/fragment-vectored branch from 55294db to 793949a Compare October 20, 2025 10:50
@embediver embediver requested a review from mkj October 20, 2025 11:00
@mkj mkj merged commit 4648498 into CodeConstruct:main Oct 22, 2025
4 checks passed
@mkj
Copy link
Member

mkj commented Oct 22, 2025

All the tests seem to just check with is_done() instead of waiting for fragment() to return SendOutput::Complete. Adding test coverage as a metric to CI and creating a tracking issue for improvements might be a reasonable thing to do.

Yes, the better code coverage would certainly be worth adding. For checking locally I've been using cargo llvm-cov --html.

In this specific case I think it'd be difficult to notice that no tests match on SendOutput::Complete from looking at coverage - there isn't a particular function that would be missing coverage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants